openvenues / php-postal

PHP bindings to libpostal for for fast international street address parsing/normalization

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

PHP restart gives 502 Bad Gateway, when adding postal.co to php.ini

JeroenSteen opened this issue · comments

I installed libpostal and the PHP extension.
On my CentOS 7 server, I added this to my /etc/php.ini

[postal]
extension = postal.so

And restarted php-fpm and nginx like so:

sudo systemctl restart php-fpm.service
sudo systemctl restart nginx.service

But when I check my webpages, I see: 502 Bad Gateway.

What can be the cause, do I need to do something extra,
maybe in my NGINX file? I have PHP 5.6.30, and nginx/1.10.3.

commented

Note that it takes a few seconds to load libpostal's models from disk into memory, possibly longer the very first time it's loaded since the model files are not in the filesystem cache. This means starting the PHP server is slower than starting nginx, so it might be that you're checking the webpage before the backend PHP app is ready to receive requests. That would explain the 502.

Try waiting a few seconds and then checking the page. Loading the models is a one-time setup cost that you pay only at server start time. Once everything's up and running, libpostal should be very high performance (10k addresses per second or more).

As far as speeding up load/setup times, you can try mlock-ing the libpostal data directory (keep the files in memory and tell the OS not to evict them) with something like vmtouch (i.e. vmtouch -m 4G -l $YOUR_DATA_DIR). On my Ubuntu machine, the difference between having files in memory vs. on-disk (SSD) is substantial, about ~3x faster to load.

If I wait after the restart of php-fpm.service, I indeed can see my webpages work again, but only for a while. After that it shows the 502 Bad Gateway again.

commented

Might be related to memory_limit (needs something like 2.5GB for libpostal plus whatever your application needs) or something along those lines. Libpostal's fully in-memory. Once everything's loaded, it's just like a library function call (C function called directly from the PHP extension), not a server. There are no sockets or anything that could timeout and cause that kind of behavior.

commented

Closing.

Libpostal 1.0 is out now, which requires less memory (around 1.8G), less likely to be killed by any supervisor processes, etc.