Un catálogo en constante crecimiento puede sobrecargar la sincronización de la API. Las tareas grandes pueden ralentizarse, agotar el tiempo de espera o detenerse prematuramente. Para gestionar los límites de velocidad de la API de PrestaShop , divide el trabajo en páginas pequeñas. Recupera solo los campos que necesitas. Limita el número de llamadas simultáneas. Además, guarda el progreso para que una tarea fallida pueda reiniciarse desde el punto correcto.
No existe una tasa de solicitudes que funcione para todas las tiendas. La tasa segura depende de tu servidor, base de datos, módulos, plan de alojamiento y configuración de red. Prueba tu propio sistema en lugar de copiar un número fijo de otro proyecto.
1.0 ¿Qué son los límites de velocidad de la API?
Un límite de velocidad establece cuántas llamadas a la API puede realizar un cliente en un tiempo determinado. Una puerta de enlace puede contabilizar las llamadas por segundo, minuto u hora. Si el cliente envía demasiadas llamadas, el servicio puede retrasar o rechazar las nuevas.
En la práctica, los límites de uso de la API de PrestaShop pueden provenir de la tienda PrestaShop o de otra capa de su infraestructura de alojamiento.
El tamaño de la solicitud es un tema aparte. Una sola llamada puede solicitar un conjunto de datos muy grande. Dicha llamada puede consumir mucha memoria, tiempo de base de datos y ancho de banda.
La solución depende del problema:
- Las llamadas que llegan demasiado rápido requieren una tarifa más baja y menos trabajo en paralelo.
- Para respuestas muy extensas, utilice páginas, filtros y menos campos.
- Cuando se presenten ambos problemas, utilice ambos conjuntos de controles.
2.0 Límites de uso de la API de PrestaShop: ¿Existe un límite fijo?
PrestaShop no publica un límite de solicitudes por segundo único para todas las tiendas. No considere un valor aleatorio de solicitudes por segundo como una regla oficial de PrestaShop.
La limitación puede provenir de otra parte de tu configuración. Apache, Nginx, un proxy, un cortafuegos o un servidor pueden bloquear el tráfico intenso. Una CDN, una puerta de enlace, un módulo personalizado o una aplicación cliente también pueden establecer una regla.
Verifique el estado HTTP, el cuerpo y las cabeceras. Luego, revise los registros de PrestaShop, el servidor y cualquier pasarela de pago. Los registros de sincronización deben incluir la hora, la ruta, el estado y el tiempo de respuesta.
Busque patrones. Quizás el error solo se presente cuando se ejecutan varios procesos. En cambio, las respuestas de gran tamaño podrían ser el desencadenante. En otros casos, los fallos comienzan después de un número determinado de llamadas. Un tiempo de espera agotado o un error HTTP 500 no demuestran que la limitación de velocidad haya causado el fallo.
3.0 ¿Por qué las solicitudes de gran tamaño a la API de PrestaShop causan problemas?
Una lista extensa puede obligar a la base de datos a ejecutar una consulta costosa. PHP necesita memoria para generar la respuesta. Posteriormente, el servidor debe enviar un archivo XML o JSON de gran tamaño.
Es difícil recuperar una solicitud grande que falla. El cliente podría tener que descargar la lista completa de nuevo, lo que aumenta la carga.
Varias solicitudes de gran volumen también pueden competir con los compradores. La guía de rendimiento de PrestaShop muestra que la velocidad depende del sistema en su conjunto. El almacenamiento en caché, el diseño de la base de datos, la configuración del servidor y los módulos son factores importantes.
No intentes enviar la solicitud más grande que tu servidor pueda procesar una sola vez. Elige una unidad más pequeña que funcione bien siempre. Además, debe ser fácil de reintentar.
4.0 Cómo gestionar grandes solicitudes de API en una tienda PrestaShop
4.1 Dividir las listas en páginas
La paginación carga una lista larga en partes más pequeñas. Una sincronización lee un grupo, lo procesa y luego obtiene el siguiente. Si falla, se reinicia desde el último punto guardado.
Este método facilita la gestión de los límites de velocidad de la API de PrestaShop, ya que cada unidad de trabajo se mantiene pequeña.
PrestaShop 9 Webservice admite un valor límite con el formato [desplazamiento,]límite . Su desplazamiento comienza en cero. Según la guía oficial, esta opción se puede utilizar para la paginación.
Figura 2. Ejemplo de paginación y selección de campos mediante servicio web en PrestaShop 7.
Figura 3. Ejemplo de paginación y selección de campos en un servicio web de PrestaShop 8.
Figura 4. Ejemplo de paginación y selección de campos en un servicio web de PrestaShop 9.
Seleccione el tamaño de página mediante pruebas. El alojamiento compartido puede requerir páginas más pequeñas que un servidor dedicado. Los datos complejos del producto también pueden requerir páginas más pequeñas.
Mantén el orden de clasificación estable, ya que los registros pueden cambiar durante una sincronización prolongada. Una fecha de cambio confiable o un ID guardado pueden contribuir a actualizaciones más seguras. Verifica qué filtros y campos de ordenación admite tu versión de PrestaShop.
4.2 Solicitar menos campos
La opción de visualización del servicio web permite obtener campos seleccionados en lugar de todos. Úsela cuando la tarea solo requiera algunos valores. Por ejemplo, una sincronización de inventario puede no necesitar descripciones completas ni otros detalles del producto.
Las respuestas más cortas se cargan más rápido y consumen menos memoria. Pruebe primero los datos complejos del producto en una tienda de prueba.
4.3 Sincronizar solo lo que cambió
Una importación completa tiene sentido durante la configuración o para una verificación ocasional. La mayoría de las tareas diarias deberían evitar tener que leer el catálogo completo de nuevo.
Cuando el recurso lo permita, obtenga solo los registros nuevos o modificados. Guarde el siguiente punto de control después de haber almacenado la página actual. Si el proceso se detiene, puede reanudarse sin omitir datos.
Elimine las llamadas duplicadas. Almacene en caché los datos estables, como las listas de países, durante un tiempo adecuado. Establezca una regla clara de caducidad o actualización para cada caché.
5. Cómo solucionar un error HTTP 429
El código HTTP 429 indica que el servicio considera que un cliente ha enviado demasiadas llamadas en un tiempo determinado. El RFC 6585 define este estado. La respuesta puede incluir Retry-After , que le indica al cliente cuándo debe intentarlo de nuevo.
Figura 1. Ejemplo de respuesta HTTP 429 con encabezados Retry-After y rate-limit.
Al investigar los límites de uso de la API de PrestaShop , considere el error 429 como una pista. No demuestra que el núcleo de PrestaShop haya establecido la regla.
Cuando tu integración recibe una respuesta 429:
- Registra la ruta, la hora, el ID del trabajo, el estado y los encabezados útiles.
- Consulte Reintentar después cuando el valor está presente y es válido.
- Pause la tarea afectada en lugar de intentarlo de nuevo inmediatamente.
- Reduzca la frecuencia de las llamadas o el número de trabajadores si el error persiste.
- Avisar al equipo cuando la tarea haya agotado todos los reintentos permitidos.
No asuma que el núcleo de PrestaShop envió la respuesta 429. Es posible que la haya enviado un proxy, una puerta de enlace, un cortafuegos, un servidor o una API de terceros. Identifique la fuente antes de modificar el cliente.
6. Cómo funcionan la lógica de reintento y la estrategia de retroceso.
Algunos fallos son temporales. Puede que se caiga la conexión de red o que un servidor sobrecargado devuelva un error. Reintentar la operación puede ayudar, pero un reintento inmediato podría aumentar la carga.
La función Backoff añade una pausa antes del siguiente intento. Si la llamada vuelve a fallar, el cliente espera más tiempo. Un pequeño retraso aleatorio puede impedir que varios procesos se activen simultáneamente. Este método es una práctica habitual en las API, no una regla integrada en PrestaShop.
Cada proceso de reintento necesita un límite. Establezca un número máximo de intentos y un tiempo de espera máximo. Reintente solo los errores que puedan resolverse automáticamente. Los datos de inicio de sesión incorrectos, los permisos faltantes y los datos no válidos requieren una corrección, no más llamadas.
Tenga especial cuidado con las solicitudes de escritura. La primera llamada podría haber modificado los datos incluso si el cliente no recibió la respuesta. Un reintento sin previo aviso podría entonces crear un duplicado o reemplazar un valor más reciente.
7. Mejores prácticas para los límites de velocidad y el rendimiento de la API de PrestaShop
Al ajustar los límites de velocidad de la API de PrestaShop , utilice varios controles pequeños en conjunto:
- Divide las listas largas en páginas y guarda un punto de control.
- Recuperar únicamente los campos y registros que necesita el trabajo.
- Establece un límite en el número de trabajadores paralelos.
- Utilice tiempos de espera de conexión y respuesta adecuados.
- Almacene en caché los datos que cambian lentamente y defina cuándo caducan.
- Aplique una reducción limitada de la carga de trabajo a los fallos a corto plazo.
- Registra los códigos de estado, los tiempos de respuesta, los reintentos y el tamaño de las páginas.
- Supervise el tiempo de ejecución de las tareas, la tasa de errores, el uso de memoria, la carga del servidor y la acumulación de tareas pendientes.
- Realizar controles de calidad exhaustivos fuera de las horas de mayor afluencia de la tienda.
- Realiza pruebas con una cantidad de datos realista antes de su lanzamiento.
Estos pasos coinciden con las recomendaciones generales de paginar listas extensas, mantener las respuestas enfocadas y supervisar el uso de la API . Sin embargo, los datos de tu tienda deben guiar cada configuración.
8. Ejemplo: Sincronización de un catálogo de productos grande
Imagina un proceso que descarga todos los detalles de cada producto. Inicia muchos procesos y no guarda el progreso. Si una solicitud caduca, todo el proceso vuelve a empezar. Entonces descarga los mismos productos sin cambios y sobrecarga aún más la tienda.
Un proceso optimizado utiliza un tamaño de página probado y solo solicita los campos necesarios. Almacena cada página y guarda un punto de control. La siguiente página se carga cuando hay capacidad disponible.
Tras un error puntual, el trabajador lo registra y espera. Si recibe una respuesta 429, sigue los detalles de reintento válidos. En ejecuciones posteriores, solo se recuperan los registros modificados cuando es posible. Una comprobación completa programada puede detectar las actualizaciones que se hayan omitido.
Este diseño puede enviar menos llamadas por segundo. Sin embargo, suele finalizar de forma más fiable porque el trabajo es constante y fácil de reanudar.
9. Crea una integración más fiable con PrestaShop.
Una buena gestión de los límites de uso de la API de PrestaShop comienza con la evidencia. Identifique la capa que aplica el límite. Luego, determine si se trata de un número excesivo de llamadas, un volumen excesivo de datos o ambas cosas.
Utilice paginación y campos seleccionados para mantener cada respuesta concisa. Añada sincronizaciones basadas en cambios, almacenamiento en caché cuidadoso y límites de procesos para reducir el tráfico. Por último, utilice registros, monitorización y reintentos limitados para que los fallos sean claros y la recuperación segura.
Antes de escalar una sincronización, revise las opciones de servicio web para su versión de PrestaShop. Pruebe la tarea completa con datos reales. En la mayoría de los casos, una tarea pequeña que se pueda reanudar es más segura que una solicitud enorme.
Para soluciones PrestaShop fiables, desarrollo de aplicaciones iOS y Android, modificaciones y migraciones de sitios web, los propietarios de tiendas pueden contactarnos en [email protected] También pueden contactarnos a través de nuestro servicio de asistencia.
